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1.  INTRODUCTION 

The  Packet  Radio  station  provides  a  variety  of  controlr 
coordination  and  monitoring  functions.  BBN"s  role  in  developing 
this  software  is  to  specify,  design,  implement  and  deliver 
programs  which  perform  these  functions.  BBN  has  additional  roles 
in  developing  internet  software  for  host  machines  and  gateway 
software  for  interconnection  of  networks.  _ _ 


During  this  quarter  BBN  personnel  participated  in  meetings 
on  both  Packet  Radio  network  and  Internetwork  issues,  as  covered 
in  section  2.  Section  2  also  covers  publications  and 
negotiations. 

Section  3  reports  important  developments  in  several  parts  of 
station  software  -  ELF,  STACON,  SPP,  TCP,  PRLOAD,  and  especially 
LABEL.  The  Labeler  has  undergone  extensive  development  and 
testing  this  quarter  with  CAP  6.0,  which  is  now  in  full  overlap 
multistation  operation. 


In  section  4  appear  reports  on  the  Internet  Protocol  and 
Transmission  Control  Protocol,  and  on  gateways.  Considerable 
effort  has  gone  into  bug  fixes  to  achieve  more  robust  and 
reliable  software  in  these  areas. 


Finally,  section  5  covers  work  on  hardware  associated  with 
BBN's  Packet  Radio  efforts  this  quarter. 


Report  No.  4671 


Bolt  Beranek  and  Newman  Inc 


2.  MEETINGS,  TRIPS  AND  PUBLICATIONS 

2.1  Meetings  and  Trips 

BBN  personnel  attended  the  Internet  Working  Group  Meeting  at 
ISI  on  January  28  to  30.  In  addition  to  status  reports  on  the 
various  IP,  TCP,  and  file  transfer  protocols  at  each  site,  system 
design  objectives  were  outlined  and  discussion  commenced  on  an 
extended  addressing  scheme.  Discussions  concerning  source 
routing  and  multi-connected  hosts  were  postponed  until  a  later 
meeting.  He  announced  the  availability  of  a  number  of  bug  fixes 
and  held  discussions  with  ISI  concerning  bug  reporting  and  fixes 
for  the  TENEX/TOPS20  internet  software. 

In  collaboration  with  other  project  participants,  we 
developed  an  agenda  and  subsequently  attended  the  CAP  6  Design 
Review  Meeting  which  was  held  at  SRI  January  26,  27,  1981.  Among 
other  developments,  this  meeting  resulted  in  a  set  of  recommended 
changes  to  the  CAP  6  Labeler,  which  became  the  center  of 
attention  for  our  work  on  that  part  of  the  system  during  this 
reporting  period  (see  Section  3.3). 

2.2  Publications 

Documentation  was  completed  for  the  CAP  5.6  and  CAP  6 
versions  of  the  station  SPP  module  and  for  the  CAP  5  and  CAP  6 
versions  of  the  Packet  Radio  Network /ARPANET  gateways.  CAP  6 
Labeler  documentation  was  prepared  and  distributed. 

Updated  user  documentation  for  the  TENEX/TOPS20  internet 
software  was  made  available  on  BBNA:  Internet  User  Queues 
(IN-USER-Q.DOC)  and  TCP  JSYS  Calling  Sequences  (TCP-JSYS.DOC) . 


Report  No.  4671 


Bolt  Beranek  and  Newman  Inc. 


2.3  Negotiations  and  Informal  Documents 

We  participated  in  discussions  with  Fort  Bragg  and  SRI  that 
focused  on  the  congestion  and  load  problems  experienced  at  Fort 
Bragg.  Our  recommendation  was  to  install  CAP  5.6  software  at 
Fort  Bragg  as  a  means  for  relieving  their  congestion  problems  and 
at  the  same  time  improving  station  performance  under  heavy  load. 
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3.  THE  PACKET  RADIO  STATION 

3.1  ELF  Operating  System 

Throughout  this  project,  it  has  been  assumed  that  Packet 
Radio  Stations  will  have  ARPANET  connections.  Recently,  there 
have  been  discussions  concerning  the  implementation  of  a  station 
which  does  not  have  an  ARPANET  connection.  As  a  first  step 
toward  this  goal,  the  ELF  system  was  modified  to  allow  the  Packet 
Radio  station  to  be  booted  from  disk  and  run  without  a 
functioning  ARPANET  connection.  The  station  is  assembled  to 
contain  an  1822  interface  to  the  ARPANET,  and  this  hardware 
interface  must  be  included  in  the  station  hardware  configuration. 
However,  if  the  connection  to  the  ARPANET  is  not  working  (for 
example,  if  the  ARPANET  IMP  is  down) ,  the  station  can  be  booted 
and  run  from  disk.  If  the  station  is  running  at  the  time  that 
the  ARPANET  connection  fails,  the  station  will  continue  to  run. 

This  modification  is  one  of  several  that  will  be  needed  to 
support  a  non-ARPANET  station.  Beyond  this,  stations  must  be 
reconfigured  to  run  without  the  1822  interface  hardware,  and  the 
more  difficult  problems  of  delivering  new  station  software  and 
debugging  station  software  must  be  solved. 

3.2  STACON  Terminal  Control  Module 

A  problem  in  the  Station  Operator  Control  Module  (STACON) 
was  corrected.  The  operator  interface  to  the  station  includes  a 
command  which  allows  the  user  to  flush  the  contents  of  the  buffer 
currently  being  printed  on  the  teletype  attached  to  the  STACON 
process.  This  feature  is  especially  useful  in  controlling 
diagnostic  printing  of  packets  received  and  sent  to  the  Packet 
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Radio  Network.  The  packet  printer  produces  a  considerable  volume 
of  data,  and  the  operator  may  wish  to  discard  the  remainder  after 
seeing  the  relevant  packet  printout.  A  fault  in  the  code  which 
implemented  this  feature  had  caused  the  station  to  hang  up  at 
random  intervals;  this  problem  was  fixed  and  new  versions  of  the 
STACON  module  were  delivered  to  all  PR  Network  sites. 

3.3  Labeler 

This  quarter's  work  on  the  Labeler  process  focused  on  the 
CAP  6  version  of  the  software.  The  design  review  meeting  at  SRI 
suggested  a  number  of  changes  to  the  labeler.  These  include: 

o  Route  patch  packets  to  establish  modifications  of  a 
route  without  the  need  for  complete  redefinition. 

o  Periodic  station  labeling. 

o  Modifications  to  the  labeler's  behavior  in  response  to  a 
request  for  a  zero-hop  route. 

o  Revisions  to  conform  with  the  new  packet  formats  which 
were  agreed  to  at  the  design  review  meeting. 

The  revised  packet  formats  made  possible  an  additional 
labeler  improvement,  namely  an  increase  in  the  maximum  route 
length  from  seven  to  eight  hops.  This  modification  was 
relatively  easy  to  accomplish  since  our  matrix  squaring  algorithm 
can  provide  eight  hop  routes  with  our  normal  three  squarings  (two 
-  four  -  eight  hops) . 

During  the  quarter,  each  of  these  modifications  was 
implemented  and  tested.  In  addition,  we  performed  general 
testing  and  debugging  activities.  We  carried  out  testing  at 
Collins,  which  focused  on  revised  packet  formats  and  route  loops. 
We  also  tested  the  CAP  6  software  at  SRI  with  emphasis  on  a 
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downloading  problem  (described  below) ,  mobile  testing,  and 
performance  bench  marking.  The  SRI  tests  also  included  the  case 
of  seven  PR  units  simultaneously  requesting  labels  (a  case  which 
exceeds  station  resources) .  Tests  at  BBN  focused  on  the  issue  of 
two  stations  simultaneously  serving  one  network. 

During  the  various  tests  we  located  and  corrected  a  number 
of  software  faults,  as  described  in  the  following  paragraphs. 

Spurious  repetition  of  route  requests  from  the  gateway  PR 
were  causing  the  Labeler  to  generate  unnecessary  repeated  route 
set-up  packets  back  to  the  PR.  The  route  requested  was  to  the 
gateway  -  a  device  attached  to  the  gateway  PR.  Consequently,  the 
problem  was  diagnosed  as  arising  from  the  absence  of  TOPs  from 
the  gateway  unit.  The  problem  was  eliminated  by  modifying  the 
gateway  software  to  emit  TOPs  in  response  to  assertion  of  its 
ready  line. 

Under  certain  conditions  the  Labeler  caused  system  failures 
with  the  error  message  "Packet  Allocation  Bug."  This  failure 
mode  was  caused  by  faulty  handling  of  an  unusual  case  of 
simultaneous  conditions: 

1.  a  label  packet  completing  its  round  trip  after  three 
transmissions,  and 

2.  a  new  label  packet  dispatched  to  the  same  PR  before 
time  out  of  the  previous  connection  slot. 

Problems  were  experienced  by  SRI  under  conditions  of 
simultaneous  downloading  and  labeling  of  a  "new”  PR  unit.  The 
difficulty  was  traced  to  a  spurious  discard  of  the  PR  in  question 
from  Labeler  tables  before  loading  was  complete. 

We  located  and  corrected  what  is  believed  to  be  the  cause  of 
an  intermittent  and  rarely  occurring  Labeler  bug  (occurrences  at 
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most  once  or  twice  per  month) .  Continued  experience  with  the 
Labeler  will  hopefully  establish  the  success  of  this 
modification. 

The  SRI  station  tests  uncovered  two  additional  Labeler 
problems  when  the  route  computation  was  increased  from  seven  to 
eight  hops  maximum.  The  first  of  these  proved  to  be  a  minor  code 
fault  whose  effect  was  to  consistently  crash  the  station  IPR. 

One  effect  of  this  first  problem  was  to  destabilize  the 
network  to  an  extent  sufficient  to  uncover  a  second  and  more 
serious  problem.  In  particular,  with  IPR  failure,  the  apparent 
network  connectivity  fluctuated  repeatedly  with  PR  units 
appearing  to  be  added  and  discarded  in  rapid  succession.  Under 
these  conditions  a  software  fault  was  activated  which  wrote  over 
random  locations  in  memory. 

Finally,  testing  at  BBN's  two  station  network  revealed  an 
ancient  Labeler  bug  which  has  existed  since  early  CAP  5.  This 
was  analyzed  and  corrected,  resulting  in  new  versions  of  both  the 
CAP  5  and  CAP  6  Labeler  releases. 

As  of  the  end  of  this  reporting  period,  we  have  delivered 
the  CAP  6.0  Labeler  software  to  SRI,  and  we  are  preparing  to 
release  the  updated  CAP  5  version  to  Fort  Bragg  pending  final 
tests  at  SRI. 

3.4  SPP  (connection)  Process 

We  released  new  versions  of  the  SPP2  (station  to  packet 
radio  protocol)  module  for  CAP  S.6  and  CAP  6.  Several  problems 
were  discovered  while  testing  the  TCP  module,  which  calls  on  the 
SPP 2  module  to  communicate  with  the  Packet  Radio  Network.  These 
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problems  were  corrected  early  in  the  quarter,  and  the  SPP2  module 
was  tested  extensively  at  SRI.  Later  an  additional  SPP2  fault 
was  found  in  the  code  for  retransmitting  packets  to  the  network. 
This  code  was  revised  appropriately  and  a  new  version  of  the  SPP2 
module  delivered  to  all  stations.  The  retransmission  fault  was 
encountered  at  both  Collins  and  Ft.  Bragg,  but  to  the  best  of  our 
knowledge  was  never  seen  in  the  station  at  SRI. 

3.5  TCP  Process 

A  TCP  for  the  CAP  5.6  station  was  delivered.  This  was  the 
first  version  that  interfaced  to  the  SPP2  process;  earlier 
versions  had  interfaced  to  the  station  connection  process  which 
implemented  the  original  SPP  protocol.  When  the  conversion  to 
SPP2  began  last  spring,  the  TCP  module  was  modified  to  interface 
to  the  new  SPP 2  module.  The  delivery  of  the  new  TCP  software  was 
delayed  until  this  quarter  due  to  the  lack  of  hardware  and 
software  needed  to  test  the  TCP  at  BBN.  The  TCP  was  eventually 
debugged  in  the  SRI  Packet  Radio  Network. 

A  version  of  TCP  for  a  CAP  6  station  was  also  released  this 
quarter.  Minor  modifications  were  made  to  accommodate  changes  in 
the  packet  header  format  and  changes  in  the  interface  to  the 
station  SPP 2  module. 

3.6  PRLOAD  process 

Early  in  the  quarter  a  new  PR  down  line  loader  (PRLOAD)  was 
delivered  to  Fort  Bragg.  After  delivery,  it  became  clear  that, 
contrary  to  previous  assurances,  the  Fort  Bragg  station  was 
lacking  the  TCU-100  time  of  day  clock  which  is  specified  as  part 
of  the  standard  station  hardware  ensemble.  Consequently, 
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references  to  the  clock  hardware  register  locations  caused  a  bus 
timeout  trap,  halting  the  station.  A  new  version  of  PRLOAD  was 
delivered,  with  all  TCU-100  references  temporarily  commented  out. 
This  permitted  the  station  to  run,  and  all  PRLOAD  features  to  be 
available,  except  that  all  time  of  day  printouts  (station  up 
time,  print  time,  enable  and  disable  loading  watch,  load  start 
and  load  finish)  printed  meaningless  time  values. 

Subsequently,  SRI  expedited  installation  of  a  TCU-100  in  the 
Fort  Bragg  station,  *»nd  we  delivered  a  normal  version  of  PRLOAD 
with  clock  routines  reactivated.  This  version  is  now  running  at 
Fort  Bragg. 

Also  during  this  quarter,  we  began  testing  PRLOAD  in  the 
multistation  environment  at  SRI.  SRI  reported  difficulties  in 
simultaneous  attempts  by  both  stations  to  load  a  single  PR.  The 
design  allows  for  such  load  attempts,  which  should  not  cause 
significant  overhead  or  problem  with  the  load  operation.  To 
diagnose  the  situation  further  details  were  needed  on  the 
functioning  of  the  load  procedure.  Consequently,  we  modified 
PRLOAD  to  print  additional  data  describing  each  load  operation 
(when  the  load  watch  feature  is  enabled) .  Beyond  the  timestamp 
and  loadee  PR  ID  which  were  already  contained  in  the  printout,  we 
added  the  loader  PR  ID,  the  packet  number  at  which  the  load 

t 

begins  (to  distinguish  new  loads  from  continuations) ,  and  the 
file  name  requested  by  the  loadee. 

At  this  writing  we  have  found  two  suspicious  occurrences 
above  and  beyond  SRI's  observation  that  many  load  attempts  begin 
and  end  before  the  PR  is  satisfactorily  loaded.  First,  we  found 
that  an  abnormally  high  fraction  of  the  load  attempts  -  often 
well  above  half  -  are  terminated  for  lack  of  any  acknowledgement 
received  by  the  station  from  the  loader  PR.  Second,  the  load 
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attempts  almost  always  start  with  packet  zero,  the  first  packet 
of  a  load,  instead  of  a  later  packet,  as  would  be  expected  in 
continuation  of  a  failed  load. 

At  the  close  of  the  quarter,  we  are  pursuing  this  matter  and 
expect  to  isolate  some  problem  in  the  station,  the  PRs,  or  the 
down  load  protocol  between  station  and  PRs. 


3.7  Support 

Software  was  delivered  to  various  sites  this  quarter  as 
follows: 

SOFTWARE  COLLINS  SRI  BBN 

IPR  CAP  6.0.6  X 

IPR  CAP  6.0.7  X  XX 

In  addition,  both  station  and  EPR  CAP  5.5  software  were 
recorded  on  each  of  two  disks  at  Fort  Bragg.  In  April,  new 
versions  of  three  station  software  modules  were  placed  on  one 
disk  at  Fort  Bragg.  The  plan  is  to  test  this  software  and  if  it 
is  acceptable,  place  it  on  the  Fort  Bragg  backup  disk  as  well. 
These  three  modules  are  an  ELF  which  no  longer  needs  an  ARPANET 
connection,  a  STACON  with  a  problem  in  the  control-0  feature 
fixed,  and  a  PRLOAD  which  fully  uses  the  time  of  day  clock. 
These  modules  are  discussed  above  in  Sections  3.1,  3.2  and  3.5 
respectively. 
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4.  INTERNETWORKING 

4.1  Internet  Protocol  and  Transmission  Control  Protocol 

We  made  progress  on  several  fronts  in  the  IP/TCP  area,  much 
of  it  guided  by  users"  questions  and  problems.  Except  for  bug 
reports,  our  interaction  with  the  users  suggested  that  the  IP/TCP 
installation  procedures  and  user-level  documentation  were  not 
sufficiently  detailed. 

The  April  1980  Installation  Guide  referenced  a  structure 
which  is  not  normally  accessible  from  the  ARPANET.  The  files  of 
interest  had  been  moved  to  BBNC  in  the  fall  of  1980  to  rectify 
this  problem  but,  due  to  departure  of  the  staff  member 
responsible,  the  documentation  had  not  been  updated  to  reflect 
the  change.  Difficulties  were  also  experienced  with  the 
operating  system  changes  required  for  installing  the  Internet  and 
Transmission  Control  Protocols  in  a  TENEX  or  TOPS20  host.  The 
trouble  lay  in  differences  between  the  corresponding  modules  of 
the  two  operating  systems:  TENEX  has  been  evolving  both  at  BBN 
and  other  sites  since  ARPA  stopped  supporting  it,  and  the  TOPS20 
changes  were  keyed  to  DEC'S  pre-release  Version  4  sources  rather 
than  the  official  release.  In  neither  case  did  the  source 
comparison  files  give  enough  context  to  pinpoint  the  required 
modifications.  Two  bug  reports  were  traced  to  a  site  having 
missed  one  of  the  required  operating  system  changes.  It  was  also 
discovered  that  many  of  the  files  on  BBNC  were  automatically 
archived  as  a  consequence  of  not  having  been  read  for  three 
months.  Insufficient  resources  on  BBNC  for  ANONYMOUS  users  lead 
to  hung  FTP  jobs  and  frustration  to  many  of  those  trying  to 
access  the  files. 
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Major  progress  has  been  made  in  resolving  these  problems. 
All  of  the  files  which  were  accessible  only  on  BBNC  have  been 
moved  to  BBNA  and  the  related  documentation  has  been  updated  to 
indicate  the  location  of  modules  related  to  TENEX,  TOPS 20 ,  IP, 
and  TCP.  Correction  files  based  on  TENEX  1.34,  the  last  version 
supported  by  ARPA,  and  DEC's  official  TOPS20  Version  4  release 
either  have  been  or  are  being  prepared.  These  files  are 
augmented  with  comments  and  several  lines  of  context  so  that,  for 
those  sites  which  are  starting  from  their  own  modified  sources, 
the  areas  where  changes  are  required  may  be  easily  located.  A 
scheme  has  been  worked  out  to  help  automate  updating  of  these 
correction  files  as  either  DEC  or  BBN  makes  future  changes. 

The  primary  user  documentation  for  internet  user  queues  and 
the  TCP  JSYSes  has  been  revised  to  remove  some  of  the  ambiguities 
and  errors  and  to  expand  the  explanations.  These  documents, 
I N-USER-Q . DOC  and  TCP- JSYS . DOC ,  are  accessible  via  the  ARPANET. 
Additions  and  changes  will  be  made  in  response  to  further 
comments  and  suggestions. 

Several  bugs  and  anomalies  were  reported  during  the  quarter. 
While  many  of  the  bug  reports,  particularly  those  from  ISI, 
included  patches  that  pinpointed  and  corrected  the  problem,  a  few 
were  too  vague  to  be  of  much  use  (e.g.,  "internet  user  queues 
don't  work") .  Many  of  the  recently  reported  bugs  have  arisen  due 
to  the  increased  use  of  the  IP/TCP  facilities. 

Several  system  crashes  were  traced  to  errors  in  the  internet 
free  storage  module,  in  particular ,  in  cases  where  free  storage 
was  exhausted.  Correction  of  these  problems  was  straightforward. 
However,  the  user  load  did  not  seem  heavy  enough  for  the  observed 
siemory  consumption.  Further  investigation  revealed  yet  another 
problem:  memory  was  being  filled  with  gateway  echo  reply 
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packets.  This,  in  turn,  lead  to  the  discovery  that  the  gateway 
module  was  not  being  being  run  often  enough  (one  bug  and  a  design 
decision) . 

Another  bug  report  indicated  that  logouts  were  hanging 
forever.  The  reason  was  not  hard  to  discover:  the  logout 
procedure  waits  for  a  connection  abort  counter  to  count  down  to 
zero;  the  counter  was  at  -1.  As  a  preliminary  cure  we  patched 
the  code  to  keep  the  counter  from  over/underf lowing;  in  the 
meantime,  progress  is  being  made  in  pursuit  of  the  bug  which 
caused  the  counter  to  be  decremented  an  extra  time. 

In  an  attempt  to  separate  the  site-dependent  bugs  from  the 
IP/TCP  bugs,  a  login  account  has  been  created  so  that  a  user 
whose  program  doesn't  work  at  the  local  site  may  try  the  program 
on  one  of  the  BBN  systems.  If  it  works  at  BBN  then  the  bug  is 
probably  due  to  modifications  made  at  the  local  site.  This 
effort  has  been  hindered  by  problems  with  the  stand  alone  test 
system.  Disk  packs,  including  the  public  structure,  were 
corrupted.  The  disk  drive/controller  was  suspect,  but  DEC'S 
diagnostics  failed  to  reveal  any  problem.  An  operating  system 
incompatibility  was  also  possible,  since  the  test  system 
alternated  between  a  DEC  monitor  and  a  BBN  monitor.  Other 
problems  intervened  until  one  of  the  disk  drives  was  moved  to 
another  BBN  system  which  had  a  disk  failure;  it  then  failed  the 
diagnostics  and  was  repaired. 

4 . 2  Gateways 

Several  modifications  were  made  to  the  gateway  software. 
Those  listed  below  were  made  to  both  the  ARPANET/Packet  Radio  Net 
gateways  and  the  ARPANET/SATNET  gateways: 


m 


A  _JL_ 


Report  No.  4671 


Bolt  Beranek  and  Newman  Inc. 


1.  Forwarding  of  internet  packets  that  are  not  internet 
version  4  packets  was  eliminated. 

2.  The  fragmentation  code  was  corrected  to  allow  the 
gateways  to  accept  the  maximum  size  packets  allowed  by 
each  network  to  which  they  are  connected  and  to 
fragment  these  packets  into  as  many  packets  as  are 
needed  to  forward  the  packet  to  its  destination. 
Earlier  versions  of  the  gateway  could  produce  no  more 
than  two  fragments  from  each  packet  received;  this 
restricted  the  maximum  size  packets  that  each  gateway 
could  accept. 

3.  A  bug  in  the  retransmission  of  routing  update  packets 
was  fixed. 


In  addition,  the  gateways  for  the  Packet  Radio  Network  were 
modified  to  support  both  CAP  5  and  CAP  6.  Currently,  software  to 
support  either  CAP  5  or  CAP  6  is  conditionally  assembled  into  the 
gateway. 

The  ARPANET/SATNET  gateways  were  also  modified  to  implement 
a  new  version  of  the  Host/SIMP  protocol.  This  protocol  was 
modified  slightly  to  correct  a  problem  in  the  Host/SIMP  reset 
mechanism  that  occasionally  caused  the  interface  to  remain  in  the 
reset  state  until  the  Host  was  restarted. 


4.3  File  Transfer  Protocol 

Development  of  file  transfer  protocol  server  and  user 
modules  occupied  about  a  third  of  the  quarter.  It  was  decided  to 
base  the  new  modules  on  the  older  NCP  FTP;  the  change  to  TCP  as 
the  data  transfer  mechanism  and  to  the  modified  protocol  of 
IEN-149/RFC-765  is  being  carried  out  at  the  same  time  to 
eliminate  an  intermediate  version.  A  single  source  for  the  NCP 

I 

and  TCP  versions  cuts  in  half  the  number  of  modules  which  will 
have  to  be  maintained.  The  server's  mail  system  interface  was 
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parameterized  to  simplify  installation  at  different  sites.  A 
test  program  was  developed  which  allows  the  server  to  be  tested 
as  a  "user  program." 


[ 
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5.  HARDWARE 

Two  hardware  activities  were  undertaken  this  quarter,  both 
centering  on  1822  interfaces.  In  the  first  we  experienced  a 
failure  of  the  SRI  1822  board  from  the  TIU  "Alta-Coma" ,  used  in 
TCP  testing.  SRI  offered  to  repair  the  board,  so  it  was  sent  to 
Menlo  Park,  and  a  replacement  picked  up  at  the  time  of  the  CAP  6 
Design  Review  Meeting. 

The  new  board  has  been  installed,  but  Alta-Coma  now  exhibits 
a  different  problem.  We  suspect  difficulty  with  the  BBN  Pluribus 
TIP  (RCC  network)  or  possibly  the  interconnecting  cable  between 
TIP  and  Alta-Coma. 

The  second  activity  involved  ACC  1822  boards  for  the 
ministation  which  needed  upgrade  to  fix  a  "last  character  short" 
problem  and  a  "last  bit  on  gather"  problem.  We  sent  the  boards 
to  ACC,  as  arranged  in  the  previous  quarter.  SRI  offered  to  test 
the  first  upgrade  in  their  lab,  and  also  to  look  for  a  "host 
ready  relay"  problem  observed  on  some  similarly  upgraded  boards. 
The  boards  passed  the  tests  at  SRI,  and  have  now  been  installed 
in  the  LSI-11/23  ministation,  permitting  further  testing  of 
ministation  software. 


OF 


INFORMATION 


j  The  reporting  period  covered  by  this  report 
has  been  extended  to  January  15,  to  align  the 
reporting  periods  with  the  contract  date.  The 
period  reported  in  QPR  No.  5,  distributed 
recently,  is  January  15,  1981  through  April  15, 
1981.  Due  to  a  clerical  error,  the  copies  of 
that  report  were  dated  as  covering  December  2, 
1980  through  February  28,  1981.  This  was  in 
error;  please  correct  your  copy  accordingly. 


